Method of detecting a source strobe event using change detection

ABSTRACT

A hub based computer system having a central hub that communicates with a plurality of satellite devices over respective link buses. Each link bus is substantially the same and adheres to a predefined link bus protocol. The link bus protocol establishes a method in which data receiving circuitry of a target device can be put into a known state during a final stage of a source strobe event such as e.g., a data transfer. Once in the known state, the source strobes are stopped on the link bus. The target device uses internal logic clocked by a system clock rather than the source strobe to continuously sample the state of the receiving circuitry to see if the state has deviated from the known state. A change detect circuit determines if the receiving circuitry has deviated from the known state and if so, detects a new source strobe event. The change detect circuit detects the new event in the less stringent clock domain, which allows greater control of the skew and asymmetry of the source strobe. This allows the system to achieve substantially higher data transfer rates than conventional source strobe systems.

FIELD OF THE INVENTION

[0001] The invention relates to computer systems, and more particularlyto a method of using change detection to detect a source strobe event ona source strobed computer system bus.

BACKGROUND OF THE INVENTION

[0002] Several of today's computer system architectures employ a sourcestrobed bus and method to transfer data between devices. In a typicalsource strobe architecture, the transmitting device transmits to thereceiving device a clock signal/strobe and data. The strobe alerts thereceiving device that valid data has been transmitted over the bus. Thisis typically referred to as a source strobe or “clock forwarding” event.Computer bus architectures such as AGP (accelerated graphics port), DDRSDRAM (double data rate synchronous dynamic random access memory), andRDRAM (Rambus random access memory) utilize source strobes in thismanner.

[0003] Source strobe techniques allow data to be transmitted at higherspeeds because the flight time and distribution delays of the clocksignal and the data are matched. Often times, data is transferred onboth rising and falling edges of the strobe. Source strobe techniques,however, require extraordinary care in matching the delays of the dataand source clock signals, as well as minimizing the asymmetry of thesource strobe itself (i.e., the differences in delays between the risingand falling edges of the strobe). In a typical source strobed bus, bothrising and falling edges of the strobe are used to clock data., butthere is a difference in the rising and falling edge delays caused byintrinsic (delay through a component) and extrinsic (delay caused byloading on the component output) delays of the system.

[0004] The intrinsic delay can typically be minimized, but the extrinsicdelay is a factor of how many loads are being driven and the wirelengths of the loads. The extrinsic delay is basically a non-linear RC(resistance times capacitance) curve making the extrinsic delay a “wildcard” in attempting to balance the delays. The on-die wire lengths mustbe managed and the number of loads must be equalized to minimize theasymmetry of the strobes. This can be illustrated with the followingexample. Let a strobe pulse have a period of 5 nano-seconds (nsecs). Ina perfect system, the 5 nsec period would yield a pulse with a 2.5 nsechigh and a 2.5 nsec low. Unfortunately, the intrinsic delays aredifferent when driving from a high to a low, than they are when drivingfrom a low to a high. The extrinsic delays are also different.Consequently, the ideal 5 nsec pulse may actually be 3 nsec high and 2nsec low. The time lost due to this asymmetry cuts into the extremelytight timing specifications of the source strobed bus and thus, must beminimized.

[0005] Typically, the core logic of the receiving device does notinterface directly with the source strobed bus. Often times, the logicnecessary to capture data from the bus is carefully placed in what iscommonly referred to as an I/O (input/output) or data macro. The I/Omacro is replicated many times along the edge of the die of thereceiving device's integrated circuit (IC). Special care is taken todistribute the source strobe to each of the I/O macros in a manner thatsubstantially guarantees a minimum skew and asymmetry of the sourceclock strobe so that the strobe may be aligned within a specific dataeye of the transmitted data. Typically, once the data has been capturedin the I/O macros, the data is transferred into another clock domain bymoving the data to the core logic of the receiving devices. The corelogic clock domain has substantially less stringent timing requirementsthan the source strobe clock domain because the core logic clocktypically operates at a slower rate than the source strobe clock.

[0006] Some of today's source strobed bus architectures such as e.g.,DDR and RDRAM use a bus protocol in which each device connected to thebus agrees on when a strobe event occurs and how many events will occur.The information concerning the timing and number of events are passedbetween the devices through signals separate from the tightly controlledsource strobed data path. In other architectures such as e.g., AGP, somesource strobe events are isochronous in nature (i.e., the event mayoccur at unknown times). These architectures must rely on one or moreflip-flops that toggle with each strobe event. The flip-flops aresampled within the less stringent clock domain to see if a strobe eventoccurred. Both of these architectures and protocols, however, experiencethe following problems that adversely impact the skew and asymmetry ofthe source strobes.

[0007] When distributed internal to an IC, the strobe delays mustclosely match the data delays. The strobe is distributed to capture datain flips-flops within the I/O macros. When the strobes are used outsidethe data path to toggle other non-data related flip-flops, the IC mustbe designed to either: (1) maintain the uniformity of the I/O macros byincluding toggle flip-flops in each macro; or (2) place toggleflip-flops are outside the tightly controlled I/O macro. The firstchoice adds substantially more load to every strobe and thus, adverselyimpacts the strobe delay and asymmetry. The second choice forces the ICdesigner to use the strobe clock outside the well controlled I/O macrosin order to toggle a single flip-flop. This induces large uncontrolledwire delays on the strobe distribution, which cuts into the budgetallotted for skew and asymmetry.

[0008] Thus, there is a desire and need for a technique to detect asource strobe event in the less stringent clock domain in a manner thatwill not adversely impact the skew and asymmetry of the internallydistributed source strobe.

SUMMARY OF THE INVENTION

[0009] The invention provides a technique to detect a source strobeevent in a clock domain that is less stringent than the source strobedomain and in a manner that will not adversely impact the skew andasymmetry of the internally distributed source strobe.

[0010] The above and other features and advantages are achieved by a hubbased computer system having a central hub that communicates with aplurality of satellite devices over respective link buses. Each link busis substantially the same and adheres to a predefined link bus protocol.The link bus protocol establishes a method in which data receivingcircuitry of a target device can be put into a known state during afinal stage of a source strobe event such as e.g., a data transfer. Oncein the known state, the source strobes are stopped on the link bus. Thetarget device uses internal logic clocked by a system clock rather thanthe source strobe to continuously sample the state of the receivingcircuitry to see if the state has deviated from the known state. Achange detect circuit determines if the receiving circuitry has deviatedfrom the known state and if so, detects a new source strobe event. Thechange detect circuit detects the new event without increasing the loadon the source strobe, without routing the strobe outside of thereceiving circuitry and in the less stringent clock domain, which allowsgreater control of the skew and asymmetry of the source strobe. Thisallows the system to achieve substantially higher data transfer ratesthan conventional source strobe systems.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The above and other advantages and features of the invention willbe more clearly understood from the following detailed description ofthe invention, which is provided in connection with the accompanyingdrawings in which:

[0012]FIG. 1 is a hub based computer system constructed in accordancewith an exemplary embodiment of the invention;

[0013]FIG. 2 is exemplary receiving circuitry used in the systemillustrated in FIG. 1;

[0014]FIG. 3 is an exemplary strobe macro used in the circuitryillustrated in FIG. 2;

[0015]FIG. 4 is an exemplary receive data macro used in the circuitryillustrated in FIG. 2;

[0016]FIG. 5 is an exemplary change detection circuit used in the systemillustrated in FIG. 1;

[0017] FIGS. 6-8 are timing diagrams illustrating the timing of thetransmit and receipt of command/address/data in accordance with anexemplary protocol of the invention;

[0018]FIG. 9 is a timing diagram illustrating the timing of placing thelink bus and receiving circuitry in to and out of the known state inaccordance with the invention; and

[0019]FIGS. 10 and 11 are exemplary source strobe event detectionmethods used in the system illustrated in FIG. 1.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020]FIG. 1 is a hub based computer system 10 utilizing link buses 40a, 40 b, 40 c (collectively referred to herein as “link buses 40”) inaccordance with an exemplary embodiment of the invention. The system 10includes a processor cluster 20, a memory device 24, a link hub 30 and aplurality of satellite devices 32 a, 32 b, 32 c (collectively referredto herein as “satellite devices 32”). The processor cluster 20 maycontain one or many processor units. Although not required to practicethe invention, if more than one processing unit is contained within thecluster 20, they are preferably identical to each other. The satellitedevices 32 can be bridges or hubs to industry standard buses, such ase.g., PCI, PCI-X and AGP, or the devices 32 can be other componentstypically found in a computer system. The devices 32 can be connected toone or more I/O devices if so desired.

[0021] The link hub 30 is connected to the processor cluster 20 by adedicated processor bus 22. The link hub 30 is connected to the memorydevice 24 by a dedicated memory bus 26. It is desirable to useddedicated processor and memory buses 22, 26 to minimize any latencies ontransfers to/from the processor cluster 20 and to/from the memory device24. The link hub 30 is connected to each satellite device 32 a, 32 b, 32c by a link bus 40 a, 40 b, 40 c (collectively referred to herein as“link buses 40”). Each link bus 40 a, 40 b, 40 c is substantially thesame. In an exemplary embodiment, the link bus 40 is a source strobedbus. As will be described below in more detail, each link bus 40 a, 40b, 40 c adheres to a predefined link bus protocol, which makes theinterface between the link hub 30 and the devices 32 generic. With theseconnections to the link hub 30, every component in the system cancommunicate with each other through the hub 30. Possible communicationpaths between the system components are represented by the dashed-lineson FIG. 1.

[0022] As will become apparent, the use of the link buses 40 and linkbus protocol allows source strobe events to be detected in a clockdomain that is less stringent than the source strobe domain of the linkbus 40. By detecting source strobe events in this manner, the system ofthe invention can substantially control and minimize any skew andasymmetry of the source strobed link bus 40, which allows for higherdata rates and also improves the overall performance of the system 10.

[0023] It is desirable that the system 10 be a high performance, I/Ointensive computer system. For example, the system 10 may be a servercomputer system or a computer workstation. It should be apparent thatthe invention is not limited to a particular type of environment/systemor to particular devices 32 used in the system 10. All that is requiredto practice the invention is to provide a link bus 40 between the linkhub 30 and the satellite devices 32 that must communicate with othersatellite devices 32, processor cluster 20 or memory device 24. Inaddition, each satellite device and the link hub 30 must adhere to thelink bus protocol.

[0024] A brief description of the link bus 40 is now provided. A moredetailed description of the link bus 40, as well as the link busprotocol, will be provided below with respect to FIGS. 6-9. Briefly, thelink bus 40 is a low pin count, high bandwidth bus that is used totransfer data and exchange messages between the components in the system10. In a preferred embodiment, the link bus 40 consists of eight orsixteen command/address/data lines, two source strobe clock signal linesand a status signal line. Communications over the link bus 40 adhere toa link bus protocol that is described below in more detail.

[0025] The link bus 40 is scaleable, and configurable to support highbandwidths such as e.g., 1 giga-byte per second (GB/s) and 500mega-bytes per second (MB/s). The link bus 40 preferably uses a quadpumping technique that transfers command, address and data informationfour times per clock period. That is, in a preferred embodiment, thelink bus 40 is a quad pumped bus. It should be noted that the link bus40 could use double pumping (i.e., transfers information two times perclock period) or a single pumping techniques if so desired. Thus, theinvention is not limited to a link bus 40 that is a quad pumped bus.

[0026]FIG. 2 illustrates exemplary receiving circuitry 100 used by thedevices connected to the link bus (e.g., link hub and satellite device).The receiving circuitry 100 of the illustrated embodiment includes eightreceive data macros 102 a, 102 b, 102 c, 102 d, 102 e, 102 f, 102 g, 102h (collectively referred to herein as “receive data macros 102”) and twostrobe macros 104 a, 104 b (collectively referred to herein as “strobemacros 104”). In an exemplary embodiment, the receiving circuitry 100 islocated along an edge of the link bus device's integrated circuit.

[0027] The first strobe macro 104 a is connected to receive a firstsource strobe clock signal L_STB and the second strobe macro 104 b isconnected to receive a second source strobe clock signal L_STB_N. Thesecond source strobe clock signal L_STB_N is the complement of the firstsource strobe clock signal L_STB. The strobes L_STB, L_STB_N are used tosignify the arrival of data on the command/address/data bus portion ofthe link bus and are described in more detail below.

[0028] The strobe macros 104 generate additional strobes STBA, STBB,STBC, STBD, which are input into the receive data macros 102. Theadditional strobes STBA, STBB, STBC, STBD are used by the receive datamacros 102 a, 102 b, 102 c, 102 d, 102 e, 102 f, 102 g, 102 h torespectively clock in the eight command/address/data bits L_CAD(0),L_CAD(1), L_CAD(2), L_CAD(3), L_CAD(4), L_CAD(5), L_CAD(6), L_CAD(7)(collectively referred to herein as “command/address/data bitsL_CAD(i)”) of an L_CAD data packet transferred on the link bus. Itshould be appreciated that FIG. 2 represents an 8-bit link bus and thatif a 16-bit or larger link bus were illustrated there would be at least16 receive data macros 102, with each macro 102 inputting a respectivebit of the L_CAD packet.

[0029]FIG. 3 illustrates exemplary strobe macros 104 a, 104 b used inthe circuitry 100 illustrated in FIG. 2. The first strobe macro 104 aincludes an I/O pad 110 a and two exclusive OR (XOR) gates 112 a, 114 a.The I/O pad 110 a is connected to receive the first strobe clock signalL_STB from the link bus. The I/O pad 110 a is connected to an inputterminal of the first and second XOR gates 112 a, 114 a such that thefirst strobe clock signal L_STB is input into the XOR gates 112 a, 114a. The second input terminal of the first XOR gate 112 a is connected toa ground potential while the second input terminal of the second XORgate 114 a is connected to a potential greater than the ground potential(e.g., Vcc).

[0030] With this configuration the strobe macro 104 a is capable ofgenerating the two strobes STBA and STBB from the single strobe inputL_STB. The second additional strobe STBB will be essentially thecomplement of the first additional strobe STBA. For example, when thelink bus strobe L_STB is high, the first XOR gate 112 a generates a highfirst additional strobe STBA and the second XOR gate 114 a generates alow second additional strobe STBB. Similarly, when the link bus strobeL_STB is low, the first XOR gate 112 a generates a low first additionalstrobe STBA and the second XOR gate 114 a generates a high secondadditional strobe STBB.

[0031] The second strobe macro 104 b includes a second I/O pad 110 b andtwo XOR gates 112 b, 114 b. The second I/O pad 110 b is connected toreceive the second strobe clock signal L_STB_N from the link bus. Thesecond I/O pad 110 b is connected to an input terminal of the third andfourth XOR gates 112 b, 114 b such that the second strobe clock signalL_STB_N is input into the XOR gates 112 b, 114 b. The second inputterminal of the third XOR gate 112 b is connected to a ground potentialwhile the second input terminal of the fourth XOR gate 114 b isconnected to a potential greater than the ground potential (e.g., Vcc).

[0032] With this configuration the strobe macro 104 b is capable ofgenerating the two strobes STBC and STBD from the single strobe inputL_STB_N. The fourth additional strobe STBD will be essentially thecomplement of the third additional strobe STBC. For example, when thelink bus strobe L_STB_N is high, the third XOR gate 112 b generates ahigh third additional strobe STBC and the fourth XOR gate 114 bgenerates a low fourth additional strobe STBD. Similarly, when the linkbus strobe L_STB_N is low, the third XOR gate 112 b generates a lowthird additional strobe STBC and the fourth XOR gate 114 b generates ahigh fourth additional strobe STBD. As noted earlier, the fouradditional strobes STBA, STBB, STBC, STBD are used by the receive datamacros to input the command/address/data bits L_CAD(i) from the linkbus.

[0033]FIG. 4 is an exemplary receive data macro 102 used in thereceiving circuitry 100 illustrated in FIG. 2. The macro 102 includes anI/O pad 120 connected to receive a command/address/data packet L_CAD(i)from the link bus 40 (FIG. 1). The macro 102 also includes four toggleflip-flops 122 a, 122 b, 122 c, 122 d (collectively referred to hereinas “toggle flops 122”), eight strobe domain flip-flops 126 a, 126 b, 126c, 126 d, 126 e, 126 f, 126 g, 126 h (collectively referred to herein as“strobe domain flops 126”), eight clock domain flip-flops 128 a, 128 b,128 c, 128 d, 128 e, 128 f, 128 g, 128 h (collectively referred toherein as “clock domain flops 128”) and a clock domain toggle flip-flop124. Hereinafter, “strobe domain” refers to the clock associated withthe link bus strobes L_STB, L_STB_N, whereas “clock domain” refers tothe less stringent core logic clock domain of the receiving component.

[0034] The first toggle flop 122 a is clocked by the first additionalstrobe STBA, the second toggle flop 122 b is clocked by the secondadditional strobe STBB, the third toggle flop 122 c is clocked by thethird additional strobe STBC, and the fourth toggle flop 122 d isclocked by the fourth additional strobe STBD. All of the toggle flops122 have their respective inverting output {overscore (Q)} connected totheir respective input data terminal D. This way, on every clock cycleof their respective strobe STBA, STBB, STBC, STBD, the output of thetoggle flops 122 non-inverting output Q will toggle between logic 1 and0 values.

[0035] The toggle flops 122 are in the strobe domain since they areessentially driven by the two strobes L_STB, L_STB_N of the link bus.The clock domain toggle flip-flop 124, on the other hand, is driven bythe clock signal CLK driving the core logic of the receiving/targetdevice. The clock domain toggle flip-flop 124 has its inverting output{overscore (Q)} connected to its input data terminal D. This way, onevery clock cycle of the core logic clock signal CLK, the output of thenon-inverting output Q will toggle between logic 1 and 0 values. Asnoted earlier, the clock signal CLK has a slower rate than the strobesof the link bus. The core logic clock domain has substantially lessstringent timing requirements than the source strobe clock domain and,as will be discussed below, will be used to determine when a new sourcestrobe event has occurred.

[0036] The non-inverting output Q of the first toggle flip-flop 122 a isinput into the enable EN inputs of the first and second strobe domainflip-flops 126 a, 126 b. The non-inverting output Q of the second toggleflip-flop 122 b is input into the enable EN inputs of the third andfourth strobe domain flip-flops 126 c, 126 d. The non-inverting output Qof the third toggle flip-flop 122 c is input into the enable EN inputsof the fifth and sixth strobe domain flip-flops 126 e, 126 f. Thenon-inverting output Q of the fourth toggle flip-flop 122 d is inputinto the enable EN inputs of the seventh and eighth strobe domainflip-flops 126 g, 126 h.

[0037] All of the strobe domain flops 126 have their data inputs Dconnected to receive L_CAD(i), where “i” represents a single bit of theL_CAD packet received from the link bus. In FIG. 2 eight receive datamacros 102 are illustrated with each macro 102 being connected to aspecified bit of the link bus (e.g., macro 102 a is connected toL_CAD(0), 102 b connected to L_CAD(1), etc.). Thus, if the macro 102illustrated in FIG. 4 where macro 102 a, then “i” would be 0 and theillustrated macro 102 would process bit 0 from up to eight L_CAD packets(since there are eight strobe domain flops 126).

[0038] The first and second strobe domain flip-flops 126 a, 126 b areclocked by the first additional strobe STBA. The third and fourth strobedomain flip-flops 126 c, 126 d are clocked by the second additionalstrobe STBB. The fifth and sixth strobe domain flip-flops 126 e, 126 fare clocked by the third additional strobe STBC. The seventh and eighthstrobe domain flip-flops 126 g, 126 h are clocked by the fourthadditional strobe STBD.

[0039] The output Q of the first strobe domain flip-flop 126 a is inputinto the data D input of the first clock domain flip-flop 128 a. Theoutput Q of the second strobe domain flip-flop 126 b is input into thedata D input of the second clock domain flip-flop 128 b. The output Q ofthe third strobe domain flip-flop 126 c is input into the data D inputof the third clock domain flip-flop 128 c. The output Q of the fourthstrobe domain flip-flop 126 d is input into the data D input of thefourth clock domain flip-flop 128 d. The output Q of the fifth strobedomain flip-flop 126 e is input into the data D input of the fifth clockdomain flip-flop 128 e. The output Q of the sixth strobe domainflip-flop 126 f is input into the data D input of the sixth clock domainflip-flop 128 f. The output Q of the seventh strobe domain flip-flop 126g is input into the data D input of the seventh clock domain flip-flop128 g. The output Q of the eight strobe domain flip-flop 126 h is inputinto the data D input of the eighth clock domain flip-flop 128 h.

[0040] The eight clock domain flops 128 are clocked by the core logicclock signal CLK. The non-inverting output Q of the clock domain toggleflip-flop 124 is input into the enable EN inputs of the first, third,fifth and seventh clock domain flops 128 a, 128 c, 128 e, 128 g. Theinverting output {overscore (Q)} of the clock domain toggle flip-flop124 is input into the enable EN inputs of the second, fourth, sixth andeighth clock domain flops 128 b, 128 d, 128 f, 128 h.

[0041] With the illustrated configuration, the output Q of the firstclock domain flip-flop 128 a yields core logic command/address/data(CAD) bit “i” for CAD(0), which is represented as CAD_i(0). The output Qof the second clock domain flip-flop 128 b is CAD_i(4), third clockdomain flip-flop 128 c is CAD_i(1), fourth clock domain flip-flop 128 dis CAD_i(5), fifth clock domain flip-flop 128 e is CAD_i(2), sixth clockdomain flip-flop 128 f is CAD_i(6), seventh clock domain flip-flop 128 gis CAD_i(3), and the eighth clock domain flip-flop 128 h is CAD_i(7).Thus, a command/address/data bit L_CAD(i) received from the link bus isshifted from the strobe domain (i.e., L_STB, L_STB_N) into the corelogic clock domain (e.g., CLK) with a simple arrangement of flip-flops.As will be discussed below, the macro 102 is designed to continuouslylatch the strobe domain data L_CAD(i) (from the strobe domain flops 126)into the core logic clock domain (via the clock domain flops 128). Thiscapability allows the invention to implement the following source strobeevent detection methods.

[0042]FIGS. 10 and 11 are exemplary source strobe event detectionmethods 200, 250 used in the system 10 illustrated in FIG. 1. Themethods 200, 250 are implemented through the use of respective linkbuses between each satellite device and the link hub, the link busprotocol described in detail below, and the receiving circuitry 100(illustrated in FIGS. 2-5).

[0043] Referring now to FIG. 10 the method 200 that is performed by thetransmitting device connected to the link bus is now described. Themethod 200 begins when the transmitting device determines whether thereis data to transmit over the link bus (step 202). If it is determinedthat there is data to transmit, the method 200 continues at step 210,where the transmitting device transmits data over the link bus. When thetransmitting device transmits this data, it will also issue the two linkbus clock strobes L_STB, L_STB_N to signify to the target device thatdata is being transmitted. The data transfer is typically initiated witha command packet that describes at least the type and size of thetransfer. The command packet allows the target to prepare for thetransfer. The protocol and message formats for a typical data transferare described below with respect to FIGS. 6-9 and Tables I-IX.

[0044] If it is determined at step 202 that there is no data to transmitat this time, the method 200 continues at step 204. At step 204, thetransmitting device sends a command packet to the target device that isintended to place the target and the link bus into a “known” state. Oneexemplary known state is an idle state IDLE, which indicates that thetransmitting device is no longer transmitting information on the linkbus. Thus, when the transmitting device determines that there is no datato transmit over the link bus, the device will build a command packethaving a command field indicative of the idle state IDLE. This idlestate IDLE will also be referred to as parking the link bus.

[0045] When the transmitting device transmits the known state commandmessage, it will also issue the two link bus clock strobes L_STB,L_STB_N to signify to the target device that data is being transmitted.At step 206 the transmitting device stops issuing the two link bus clockstrobes L_STB, L_STB_N. This will keep the receiving circuitry 100 (FIG.2) of the target from clocking in data from the L_CAD portion of thelink bus while the link bus is IDLE or parked.

[0046] Referring now to FIG. 11 the method 250 that is performed by thetarget device connected to the link bus is now described. The method 250begins when the receiving circuitry 100 (FIG. 2) clocks in the link busstrobes L_STB, L_STB_N and the strobe domain data L_CAD, if there arestrobes L_STB, L_STB_N and strobe domain data L_CAD to input (step 252).If the bus is parked (i.e., the bus is idle after the transmittingdevice issues the idle command) then step 252 does not occur. At step254 the strobe domain data that is latched in the strobe domain flops126 (FIG. 4) is sampled into the clock domain flops 128 (FIG. 4). Asnoted earlier, even if there are no link bus strobes L_STB, L_STB_N, theclock domain flops 128 (FIG. 4) are capable of latching the latchedstrobe domain data into the clock domain. If the last strobe domain dataL_CAD received was the IDLE command packet, then the latched data willbe the IDLE command packet data.

[0047] At step 256, the method 250 continues by determining whetherchange detect circuitry should check the data latched in the clockdomain to see if a new source strobe event has occurred. Since thetransmitting device issues a command packet identifying the size of atransfer, and the methods 200, 250 of the invention are only seeking todetect a new source strobe event, there is no reason to check thelatched data until the prior source strobe event has completed. Forexample, if the transmitting device issues a command packet identifyinga data transfer of N packets, then a new event cannot be received untilafter the N packets have been received. Thus, the receiving circuitrydoes not have to check for a new event until packet N+1 is received (orexpected to be received). Thus, at step 256 the method checks a packetcount or other indicator to determine if the latched data should bechecked.

[0048] If at step 256 it is determined that the change detect circuitryshould check the data latched in the clock domain to see if a new sourcestrobe event has occurred, then the method 250 continues at step 258. Atstep 258 change detect circuitry compares data latched in the clockdomain to the known state. If, for example, the idle state IDLE is beingused as the known state, then the change detect circuitry compares thelatched data to the IDLE command. At step 260 it is determined whetherthe clock domain data is set to the known state. If the clock domaindata is in the known state (e.g., IDLE), then no new source strobe eventhas been detected and the method 250 completes.

[0049] If at step 260 it is determined that the clock domain data is notin the known state, then the method 250 continues at step 262, where anew command/address/data from the link bus is processed because a newsource strobe event has been detected by the change detect circuit. Atthis step, information about the new event is obtained, such as a packetcount, to aid in the detection of the next source strobe event (i.e.,information need for step 256).

[0050]FIG. 5 is an exemplary change detection circuit 130 used in thesystem 10 (illustrated in FIG. 1) to execute steps 258 and 260 of themethod 250 (FIG. 11). The change detection circuit 130 includes a clockdomain toggle flip-flop 132, two clock domain data flip-flops 134, 136,two clock domain latches 138, 140, two compare circuits 142, 144 and anAND gate 146. It should be appreciated that this is only an exemplaryembodiment for the change detection circuit 130 and that the inventionis not limited to any specific circuitry.

[0051] The clock domain toggle flip-flop 132 is driven by the core logicclock signal CLK. The clock domain toggle flip-flop 132 has itsinverting output {overscore (Q)} connected to its input data terminal D.This way, on every clock cycle of the clock signal CLK, the output ofthe non-inverting output Q will toggle between logic 1 and 0 values. Theoutput of the non-inverting output Q is used to enable the two clockdomain data flip-flops 134, 136.

[0052] The two clock domain data flip-flops 134, 136 are clocked by thecore logic clock signal CLK. The first clock domain data flip-flop 134inputs all of the data bits from CAD(3:0) from the data macros 102 (FIG.2). In an exemplary embodiment, this is at least 32-bits of data (8-bitseach from CAD(3), CAD(2), etc.). The second clock domain data flip-flop136 inputs all of the data bits from CAD(7:4) from the data macros 102(FIG. 2). In an exemplary embodiment, this is at least 32-bits of data(8-bits each from CAD(7), CAD(6), etc.). It should be noted that if a16-bit command/address/data bus is used, then the change detectioncircuitry would be include additional circuitry to input CAD(15:8).

[0053] The output Q of the first clock domain data flip-flop 134 isinput into the data input D of the first latch 138 and the first comparecircuit 142. The output Q of the second clock domain data flip-flop 136is input into the data input D of the second latch 140 and the secondcompare circuit 144. The first and second latches 138, 140 are clockedby the core logic clock signal CLK. The first latch 138 is used to latchand output the output Q from the first clock domain flip-flop 134.Similarly, the second latch 140 is used to latch and output the output Qfrom the second clock domain flip-flop 136.

[0054] The first compare circuit 142 inputs an output Q from the firstclock domain flip-flop 134 and the first latch 138 and the secondcompare circuit 144 inputs an output Q from the second clock domainflip-flop 136 and the second latch 140. In operation, the comparecircuits 142, 144 compare their respective inputs (i.e., the current CADinformation from the clock domain flip-flops 134, 136 and the prior CADinformation from the latches 138, 140) to see if they are equal. If therespective inputs are equal, the compare circuits 142, 144 output afirst signal from their respective equal output EQ. If the respectiveinputs are not equal, the compare circuits 142, 144 output a seconddifferent signal from their respective equal output EQ. For example, alogic “1” could be output when the compare circuits 142, 144 detect thattheir respective inputs are equal and a logic “0” could be output whenthe compare circuits 142, 144 detect that their respective inputs arenot equal.

[0055] The outputs of the first and second compare circuits are inputinto the AND gate 146. The third input of the AND gate 146 is connectedto a CHECK STATE signal representing when it is time to check for a newevent. As noted above with respect to step 256 of method 250 (FIG. 11),it may be desirable to check for a new event only after the last eventhas completed. Thus, the CHECK STATE signal will be generated by thecore logic only when it is possible for a new event to occur. In anexemplary embodiment, the CHECK STATE signal will be generated with alogic “1” value when it is time to check for a new event and will not begenerated (or driven to a logic “0” value) when it is not time to checkfor a new event.

[0056] In one exemplary embodiment, the known state is the bus idlestate IDLE and thus, the CHECK STATE signal is indicative of when it istime to check for the idle state IDLE. It should be noted that thecompare circuits 142, 144 should be designed such that if theirrespective inputs are equal, then the value of their respective outputsEQ should equal the value of the CHECK STATE signal used to indicatethat it is time to check for a new event.

[0057] The output of the AND gate 146 is a new event signal NEW EVENT.If the circuitry 130 detects a new event, then the new event signal NEWEVENT will have a first logic level (e.g., logic “1”). If the circuitry130 does not detect a new event, then the new event signal NEW EVENTwill have a second logic level (e.g., logic “0”). In operation, the ANDgate 146 will always output a new event signal NEW EVENT indicating thata new event has not been detected when the CHECK STATE signal indicatesthat it is not time to check for a new source strobe event.

[0058] When the CHECK STATE signal indicates that it is time to checkfor a new source strobe event, then the outputs from the two comparecircuits 142, 144 will determine if a new event has occurred. That is,if the respective outputs of the two compare circuits 142, 144 indicatethat their respective inputs are equal, then the NEW EVENT output of theAND gate 146 will be a value indicative of the known state, which meansthat a new event has not occurred (e.g., the bus is in the idle stateIDLE). If the respective outputs of either or both of the two comparecircuits 142, 144 indicate that their respective inputs are not equal,then the NEW EVENT output of the AND gate 146 will be a value indicativeof a state other than the known state, which means that a new event hasoccurred (e.g., the bus is not in the idle state IDLE). As noted above,this detection of the new event or the known state is made in the corelogic clock domain.

[0059] Thus, the invention allows source strobe events (e.g., commandand data transfers) to be detected in the core logic clock domain, whichis less stringent than the source strobe domain of the link bus.Moreover, the invention allows the detection of the new events withoutunnecessary loading the source strobes L_STB, L_STB_N and withoutrouting the strobes L_STB, L_STB_N externally from the macros of thereceiving circuitry. By detecting source strobe events in this manner, ahub based computer system using the invention can substantially controland minimize any skew and asymmetry of the source strobed link bus. Thisallows for higher data rates and also improves the overall performanceof the system.

[0060] Referring to FIGS. 6-9, an exemplary link bus and link busprotocol are now described. It should be noted that memory transferswill most likely make up the majority of the transfers across the linkbus. Burst operations form the vast majority of transfers from thesatellite devices as I/O devices, but partial reads/writes shall also besupported. It is desirable for burst transfers to be aligned on 64-byteboundaries. If a PCI-X device communicates over the link bus, the devicewill indicate it's intention to transfer up to 4 K bytes and if PCIdevices are used, PCI pre-fetching can also support bursts greater than64-bytes. Thus, it is desirable for the link bus to include a mechanismto request 4 K bytes of data per request. Partial transfers willtransfer less than the minimum burst size. These transfers are primarilypartial writes with byte enables. Byte enables must then be encoded inthe link bus request phase.

[0061] In an exemplary implementation of the link bus protocol, eachsatellite device will appear to software as a bridge of some sort. Thisallows a simple address decode model for each of the satellite devices.For example, in systems including PCI buses, each satellite device willreport as a PCI-PCI bridge and in systems using PCI-X buses, eachsatellite device will report as a PCI-X-PCI-X bridge. In these examplesystems, only the south bridge, which may itself be a satellite device,will report as a different device. The PCI bridge model works well todecode transfers from the satellite device going upstream to the linkhub. The link hub will, by necessity, need to know the addresses mappedin each of the satellite devices in order to move transfers downstream,and in a lateral direction (peer to peer transfers).

[0062] In PCI systems, for example, PCI configuration address space isused to allocate memory resources, as well as other configurationattributes, in the system. Registers within the PCI configuration spaceare used to define memory and I/O address spaces. This configurationinformation is used to decide addresses of transfers going both upstreamand downstream from the link hub. Addresses that are going downstreammust fall within a programmed address range while addresses goingupstream must fall outside a programmed address range. Due to the hubbased architecture of the system, configuration information must existin the upstream device (e.g., link hub) and the downstream device (e.g.,satellite device). This means that the function of a PCI-PCI bridge, forexample, is performed by two independently operating devices—one deviceinitiating downstream transfers and one device initiating upstreamtransfers.

[0063] Thus, the same configuration information must exist in both thesatellite device and the link hub. One method of distributingconfiguration information in a hub based architecture is described inco-pending application Ser. No. ______, entitled “Link Bus for a HubBased Computer Architecture” (Attorney Docket No. M4065.0366/P366),which is hereby incorporated by reference in its entirety.

[0064] As noted above, once the link hub and the various devices areconfigured, data transfers can be made throughout the system. Becausesome of today's (and future) industry standard buses support splittransactions, it is desirable for the link bus protocol to support splittransactions as well. For example, the PCI-X standard supportssplit-transactions to free up the bus. A split-transaction request isissued, and some time later the target of the original request issues asplit completion. This is similar to the deferred request of someprocessor families, which would then be responded to by the target usinga defer reply. The split-transaction mechanism is an elegant way to freeup the bus for other transactions while a target is kept busy performingthe transaction request. The link bus protocol also utilizes thesplit-transaction mechanism.

[0065] Some additional industry standard rules shall also be observed bythe link bus protocol. For example, PCI-X includes a status bit thatindicates the transfer can use relaxed ordering rules. This will speedup transfers by eliminating buffer flushing along the data path. It isdesirable that the link bus protocol include relaxed order status. Inaddition, PCI-X includes a status bit that indicates the transfer doesnot need to perform a snoop operation on the processor caches. In acached system, snooping is performed to find any modified data in thecaches. That is, find the freshest data in the caches. Snooping is amethod used to ensure the coherency of memory in a system employingmemory caches. Transfers of this type may proceed directly to memorywithout snooping the processor caches. It is desirable that the link busprotocol include a “no snooping” option as well.

[0066] In a preferred embodiment, the link bus consists of an 8-bit or a16-bit command/address/data bus (L_CAD) and the two source strobed clocksignals L_STB, L_STB_N as shown below in Table I. A single status signalL_ST is used to exchange flow control information between devices.Optionally, byte enables may be issued coincident with each data phase.Exemplary formats for the L_CAD, L_STB, L_STB_N and L_ST signals will bedescribed below in more detail. TABLE I Signal Type Count DescriptionL_CAD[15:0] In/Out 16  Link bus command/address/data L_CAD[17:16] In/Out2 Optional byte enables for write data. Not needed for all link busconfigurations. L_STB In/Out 1 Link bus strobe L_STB_N In/Out 1 Link busstrobe Not L_ST In/Out 1 Link bus status

[0067]FIG. 6 is an exemplary diagram illustrating the timing of thetransferring of command/address/data onto the link bus by one of thesatellite devices (or link hub). In one embodiment of the link bus, thesystem clock will be distributed internally by a phase-locked loop (PLL)capable of generating both a “1X” clock (i.e., data transferred one-timeper clock tick) and “4X” clock (i.e., data transferred four-times perclock tick). FIG. 6 illustrates the 1× and 4X clock signals,command/address/data (“CAD”) from the core logic of the device, CADlatched in an I/O shell and the link bus signals L_CAD, L_STB andL_STB_N.

[0068] In the transmit waveform of the link bus) CAD is issued from thecore logic on the device in the 1X clock domain and captured in an I/Omacro (i.e., I/O shell) in the 1X clock domain. Once in the I/O macro,the CAD is multiplexed from the 1X clock domain to the 4× clock domain.Once in the 4X domain, the CAD is driven onto the link bus as the L_CADsignals. The source strobed clock signals L_STB, L_STB_N are also drivenonto the link bus to generate strobes at two-times the system clockfrequency. The source strobed clock signals L_STB, L_STB_N are driven attwo-times the system clock frequency so the receiver only has to workwith one edge of each strobe L_STB, L_STB_N, eliminating concerns aboutstrobe asymmetry.

[0069] In an exemplary embodiment, two strobe signals L_STB, L_STB_N areoperating at twice the clock frequency, providing a total of four strobeevents for each clock cycle. In the exemplary embodiment, the link busprotocol will not allow fewer than four strobes per clock cycle. 64-bitsof data may therefore be transferred every clock cycle in a 16-bit linkbus configuration. Similarly, in a 8-bit link bus configuration, 32-bitsof data may be transferred per clock cycle. It is also desirable fordata to be transferred along 8-byte address boundaries. Thus, a 16-bitlink bus configuration may transfer 8-bytes in one clock cycle, whilethe 8-bit link bus transfers data in two clocks cycles.

[0070] Once the signals are transmitted onto the link bus, anotherdevice (i.e., the target) may receive the signals in accordance with thelink bus protocol. Referring now to FIG. 7, the timing of the receipt ofthe link bus command/address/data L_CAD and source strobed clock signalsL_STB, L_STB_N is now described. The target device will receive theL_CAD and strobes L_STB, L_STB_N after some delay. The receivedinformation should then be synchronized back into the 1X clock domain.As described above, for each strobe of the source strobed clock signalsL_STB, L_STB_N, there are a series of latches or flip-flops in thereceiver I/O macro (identified in FIG. 7 as A, D, C, and D flip-flops).L_CAD information is clocked into each flip-flop as CAD information in aping-pong fashion so that timing may be met. The CAD is then transmittedto the 1X clock domain in the I/O macro by assembling each of the datain the A, B, C, D flops into a wider data path in accordance with rulesthat will meet timing requirements between the strobe domain and the 1Xclock domain. Once in the 1X clock domain, the CAD is available to thereceiver's core logic.

[0071]FIG. 8 shows a generalized view of the transfer ofcommand/address/data from the time that it is available in the corelogic of the transmitting device, to the time that it is available tothe core logic of the receiving device. This generalized view does notshow the intermediate steps of quad pumping across the link bus. For thepurpose of illustration, it is assumed that CAD is quad pumped asillustrated in FIGS. 6 and 7. It should be noted that it takes fiveclock cycles from the time a state decision is made in the transmittercore (time T0), to the time the receiver core can act on thatinformation (time T4).

[0072]FIG. 9 is a timing diagram illustrating the timing of placing thelink bus and the receiving circuitry in to and out of the known state inaccordance with the methods 200, 250 (FIGS. 10-11) of the invention. Attime T0 the transmitting device issues a command to place the link busin to the known state. In this illustrated embodiment, the known stateis the idle state IDLE. Thus, the transmitting device issues an IDLEcommand packet on the link bus.

[0073] After issuing the IDLE command, the transmitting device stopsissuing the source strobes L_STB, L_STB_N (times T1 and T2). The targetclocks in the last packet of L_CAD information and continuously samplesthe L_CAD into the core logic clock domain (e.g., the “1X clock” in FIG.9). At time T3 the transmitting device begins a new source strobe eventby issuing a transfer request on the link bus and both source strobesL_STB, L_STB_N. The receiving circuitry of the target, which has beenclocking in the L_CAD information from the last transfer prior to theIDLE command, clocks the new request into the core logic (as describedabove with reference to FIGS. 2-4). Once the new request is clocked intothe core logic clock domain flip-flops of the target, the change detectcircuit determines that there is a new source strobe event, which issubsequently processed in the core logic.

[0074] It should be appreciated that the above described timing diagramsare mere illustrations of exemplary embodiments of the link bus and linkbus protocols and that the invention is not limited to any specifictiming.

[0075] It is desirable for data to be paced only on certain naturallyaligned data boundaries (ADB's). An ADB is an amount of data that may betransferred across the link bus in a certain number of clock cycles. Inone embodiment, the ADB is the amount of data that may be transferredacross the link bus in eight clock cycles. Examples of ADBs wouldinclude 64-bytes for a 16-bit link bus and 32-bytes for an 8-bit linkbus. The pacing of information on the link bus is described inco-pending application Ser. No. ______, entitled “Method of Pacing andDisconnecting Transfers on a Source Strobed Bus” (Attorney Docket No.M4065.0405/P405), which is hereby incorporated by reference in itsentirety.

[0076] As noted above, in addition to the clock forwarded quad-pumpedcommand/address/data portion of the link bus, there is a single-bit linkstatus signal L_ST. The link status signal L_ST time multiplexesarbitration and data flow information. For every transaction, one deviceconnected to the link bus will serve as a bus master and the otherdevice will serve as the bus slave. Data may be stalled by either themaster, or the slave by defining certain windows during a transfer inwhich the status may be driven and observed. In a typical situation, thetransferring device serves as the master, while the receiving device(i.e., the target) serves as the slave. The target may request itsdesire to become the link master by time multiplexing an arbitrationrequest on the status signal L_ST.

[0077] Each device connected to a particular the link bus is given theopportunity to arbitrate for the link bus. Typically, when a sourcestrobed bus is used, one device (e.g., memory controller) always servesas the bus master, while the other device (e.g., memory device) alwaysserves as the bus slave. In the present invention, however, eitherdevice can serve as the master. In one exemplary embodiment of theinvention, the link bus follows a round-robin arbitration method. Due tothe split-transaction nature of the link bus, both devices must have afair opportunity to access the link bus to prevent deadlocks. There isno central arbitration point which decides who is granted the bus.Instead, the arbitration is decentralized with each device observingcertain state information to decide which of the devices is the busmaster. A device that is not currently the bus master (i.e., the target)may request to become a bus master by time multiplexing an arbitrationrequest on the link status signal L_ST. The arbitration protocol allowsbus parking, and back-to-back transfers to minimize latencies andimprove performance. The arbitration of the bus is distributed betweenthe two Link entities, as is described in co-pending application Ser.No. ______, entitled “Arbitration Method for a Source Strobed Bus”(Attorney Docket No. M4065.0404/P404), which is hereby incorporated byreference in its entirety.

[0078] Now that the basic functions and timing of an exemplary link busand link bus protocol have been described, the following now describesthe format and content of the information packets transmitted over thelink bus. One packet of information is the command packet. A commandpacket is issued by the current link bus master and may includeinformation such as command, address, transfer count, as well as otherattributes needed in the system. An exemplary command packet format isillustrated below in Table II. It should be noted that the formattingillustrated in Table II (and Tables III-IX) are examples of the type offormat/content that may be used to implement the link bus and link busprotocol. Specific bit fields or sizes of the fields are not given inthe Tables because the invention is not limited to any specific fieldsize or position (i.e., bit position) within the packet. TABLE II FieldDescription Command Bus Command Address During memory transactions thisfield represents a portion of the address. Count/Enable During blocktransfers, this field represents the number bytes to transfer. Duringpartial transfers this field represents byte enables. Command attributeThe command attribute field is defined differently for split completioncommands and all other commands. For split completion commands thisfield indicates the completion status of an earlier requested transfer.For all other commands the field indicates transfer attributes of thecurrent request.

[0079] As can be seen from Table II, an exemplary command packet mayinclude command, address, transfer count or byte enable and attributefields. Exemplary commands that can occupy the command field areillustrated below in Table III. In an exemplary embodiment, the link bussupports split transactions. Thus, the command attribute field isdefined differently for split completion commands than all other commandrequests. Table IV illustrates exemplary definitions for the attributefield for all normal commands, while Table V illustrates exemplarydefinitions for the attribute field for the split completion command.TABLE III Command Description Idle Bus Idle, no requests. All other bitsare inactive to conserve power. Split Completion Split completion reply.Issued in response to a previously issued request to transfer read data,or transfer completion status. Message Read Message read request such asprocessor interrupt acknowledge, flush, fence. Message Write Messagewrite request such as processor special cycles, NOP, interruptmessaging, and error status messaging. Block Memory Read Request amemory read of e.g., 1 to 4K bytes. Large block memory reads are thepreferred transfer method. Block Memory Write Request a memory write ofe.g., 1 to 4K bytes. Byte enables for all requested bytes are assumedactive. Large block memory writes are the preferred transfer methodPartial Memory Read Request a memory read of bytes less than the minimumburst size read. Partial Memory Write Request a memory write of bytesless than the minimum burst size write. Configuration Read ReadConfiguration data. Address is encoded similar to PCI Type 1configuration cycles. The Link target must decode to determine iftransfer is target internally or to subordinate bus. Configuration WriteWrite Configuration data. Address is encoded similar to PCI Type 1configuration cycles. The Link target must decode to determine iftransfer is target internally or to subordinate bus. I/O Read I/O readdata. I/O Write I/O write data. Reserved Reserved Commands.

[0080] TABLE IV Field Description Relaxed Ordering Indicates that thetarget may use relaxed ordering Rules rules to transfer data. No SnoopIndicates that memory accesses do not need to be snooped. Not valid fornon-memory transfers. No Split-Completion Indicates that nosplit-completion message is expected by the master. For writes, thisindicates that the transfer is posted, and the master assumes the targetshall perform the steps necessary to complete it on the subordinate bus.Lock Indicates the status of bus lock issued by the processor. Onlyvalid during processor initiated transfers. Note this does not lock thelink bus, only the target bus subordinate to the link bus.

[0081] TABLE V Field Description Retry Indicates that the target hasretried the transaction. Request Complete Indicates that the read/writerequest has completed normally. RD/WR Indicates that the splitcompletion is issued in response to a read or write request. No DataIndicates that no data is transferred, and the value of the Count/Enablefield is invalid. Split Completion Error Indicates that an erroroccurred during the split completion. Split Completion Error Indicatesthe type of completion error as defined Status in e.g., PCI-X.

[0082] The address field identifies the address of the target request.The address field is slightly different for each of the commands. TableVI illustrates one way in which the address field may vary dependentupon the command field. TABLE VI Command Address Field Description IdleAll address bits in the low power state. Split Completion. Copy of theoriginal split-transaction tag issued with the original request. Allother bits are reserved. Message Read See Table VII Message Write SeeTable VIII Block Memory Read Address of the memory request. Block MemoryWrite Partial Memory Read Address of the memory request. Partial MemoryWrite Configuration Read Address of Configuration address register(e.g., Configuration Write I/O register). I/O Read Address of the I/Orequest. I/O Write Reserved Reserved. Should be driven to the low powerstate.

[0083] The address field requires a more detailed definition for messageread and write commands. Exemplary address fields for write commands arefound in Table VII, while exemplary address fields for read commands arefound in table VIII. TABLE VII Command Description Shutdown SpecialCycle Processor special cycle Halt Special Cycle Processor special cycleStop Clock Grant Processor special cycle Special Cycle x86 architectureProcessor special cycle specific NOP No Operation. May be issued fromany link device. Interrupt Event One or more interrupt lines from asatellite have changed states. PERR Event Change in PERR status. SERREvent Change in SERR status.

[0084] TABLE VIII Command Description Interrupt Acknowledge Processorinterrupt acknowledge Flush Flush buffers Fence Fence buffers

[0085] In an exemplary embodiment, a split-transaction tag is used toidentify the source of a request so that it may be later replied to witha split completion request. The tag is defined to interface with similartags used for various processors and is described in Table IX. TABLE IXField Description Agent Type Identifies the Agent as a processor, linkbus satellite, or link hub. Agent Tag Identifies a particular request ofthe initiating Agent. This field is large enough to carry informationfrom the processor cluster, or a PCI-X agent Agent Bus Number The PCIBus number of the requesting device Agent Device Number The PCI devicenumber of the requesting device Agent Function number The PCI functionnumber of the requesting device

[0086] Now that the exemplary format/content of command packets havebeen described, the following now describes an exemplary set of rulesrequired to adhere to the link bus protocol. As much of the controlinformation is time multiplexed across the status signal L_ST, there arecertain rules that must be observed by the link master and slave todetermine when information is valid and when the information can bedriven on the link bus. When a device drives the status signal L_ST low,it will always drive it high one clock before tri-stating the signalL_ST.

[0087] Another rule governs the response of the target device (i.e.,receiver). For example, a response must be issued by the target 1 clockcycle after observing the transfer request in the clock domain. Theresponse must be observed by the master 4 clocks cycles after issuingthe transfer request in the clock domain. Otherwise the response will bedeemed invalid. In addition, the transfer shall be terminated by themaster 1 clock after observing a response retry signal. It should benoted that the link bus protocol requires other rules governing thearbitration and data stalls processes. These rules, however, are notdescribed herein because they are described in the co-pendingapplications previously identified above.

[0088] As noted earlier, the present invention capitalizes on the linkbus and the link bus protocol to allow satellite devices to detectsource strobe events such as data transfers in a clock domain that isless stringent than the source strobe domain. Moreover, the inventionallows the detection of the new events without unnecessary loading thesource strobes L_STB, L_STB_N and without routing the strobes L_STB,L_STB_N externally from the macros of the receiving circuitry. Bydetecting source strobe events in this manner, the system of theinvention can substantially control and minimize any skew and asymmetryof the source strobed link bus, which allows for higher data rates andalso improves the overall performance of the system.

[0089] It should be noted that the formats, timings and otherdefinitions describing the link bus and the link bus protocol are mereexamples. The invention is not to be limited to the specific examplesdescribed herein.

[0090] While the invention has been described and illustrated withreference to exemplary embodiments, many variations can be made andequivalents substituted without departing from the spirit or scope ofthe invention. Accordingly, the invention is not to be understood asbeing limited by the foregoing description, but is only limited by thescope of the appended claims.

What is claimed as new and desired to be protected by Letters Patent ofthe United States is:
 1. A method of detecting a source strobe event ina processor based system, the system comprising a first device coupledto a second device by a link bus, the link bus comprising at least onesource strobe signal line associated with a first clock domain, saidmethod comprising the steps of: inputting at one of the first and seconddevice information associated with the source strobe event from the linkbus, the information being input into first circuitry associated withthe first clock domain; sampling the input information from the firstcircuitry into second circuitry associated with a second clock domain;determining from the sampled information whether the link bus is in aknown state; and processing the source strobe event if it is determinedthat the link bus is not in the known state.
 2. The method of claim 1,wherein the known state is a link bus idle state.
 3. The method of claim1, wherein the information associated with the source strobe event is acommand packet transmitted over the link bus from the other one of thefirst and second device.
 4. The method of claim 1, further comprisingthe step of ignoring the information if it is determined that the linkbus is in the known state.
 5. The method of claim 4, wherein if it isdetermined that the link bus is in the known state, said method furthercomprises: repeating said inputting step to said determining step untilit is determined that the link bus is not in the known state.
 6. Themethod of claim 1, wherein said determining step comprises: determiningwhether the sampled information should be presently checked; and if itis determined that the information should be presently checked,comparing the sampled information to information indicative of the knownstate.
 7. The method of claim 6, wherein said step of determiningwhether the sampled information should be presently checked comprises:checking a characteristic of a prior source strobe event; anddetermining from the checked characteristic whether it is possible for anew source strobe event to occur at present.
 8. The method of claim 7,wherein the characteristic is a packet count of the prior source strobeevent.
 9. The method of claim 1, wherein said inputting step comprises:detecting a source strobe propagating in the at least one source strobesignal line; and inputting the input information from acommand/address/data portion of the link bus.
 10. The method of claim 9,wherein said sampling step comprises: generating simulated sourcestrobes based on the detected source strobe; latching the inputinformation within the first circuitry using the simulated sourcestrobes; and clocking the latched information into the second circuitrybased on a clock signal generated in the second clock domain.
 11. Themethod of claim 1, wherein the other one of the first and second deviceterminates the issuance of source strobes on the source strobe line at acompletion of the source strobe event.
 12. The method of claim 11,wherein the other one of the first and second device continues theissuance of source strobes on the source strobe line at a beginning of anew source strobe event.
 13. A method of detecting a source strobe eventin a processor based system, the system comprising a hub device coupledto a processor by a processor bus and coupled to a memory device by amemory bus, the hub device being connected to a satellite device by alink bus, the link bus comprising at least one source strobe signal lineassociated with a first clock domain, said method comprising the stepsof: inputting at one of the hub device and the satellite deviceinformation associated with the source strobe event from the link bus,the information being input into first circuitry associated with thefirst clock domain; sampling the input information from the firstcircuitry into second circuitry associated with a second clock domain;determining from the sampled information whether the second circuitry isin a known state; and processing the source strobe event if it isdetermined that the second circuitry is not in the known state.
 14. Themethod of claim 13, wherein the known state is an idle state.
 15. Themethod of claim 13, wherein the information associated with the sourcestrobe event is a command packet transmitted over the link bus from theother one of the hub device and satellite device.
 16. The method ofclaim 13, further comprising the step of ignoring the information if itis determined that the second circuitry is in the known state.
 17. Themethod of claim 16, wherein if it is determined that the secondcircuitry is in the known state, said method further comprises:repeating said inputting step to said determining step until it isdetermined that the second circuitry is not in the known state.
 18. Themethod of claim 13, wherein said determining step comprises: determiningwhether the sampled information should be presently checked; and if itis determined that the information should be presently checked, sendinga signal to change detect circuitry such that the change detectcircuitry compares the sampled information to information indicative ofthe known state.
 19. The method of claim 18, wherein said step ofdetermining whether the sampled information should be presently checkedcomprises: checking a characteristic of a prior source strobe event; anddetermining from the checked characteristic whether it is possible for anew source strobe event to occur at present.
 20. The method of claim 19,wherein the characteristic is a packet count of the prior source strobeevent.
 21. The method of claim 13, wherein said inputting stepcomprises: detecting a source strobe propagating in the at least onesource strobe signal line; and inputting the input information from acommand/address/data portion of the link bus.
 22. The method of claim21, wherein said sampling step comprises: generating simulated sourcestrobes based on the detected source strobe; latching the inputinformation within the first circuitry using the simulated sourcestrobes; and clocking the latched information into the second circuitrybased on a clock signal generated in the second clock domain.
 23. Themethod of claim 13, wherein the other one of the hub device and thesatellite device terminates the issuance of source strobes on the sourcestrobe line at a completion of the source strobe event.
 24. The methodof claim 23, wherein the other one of the hub device and the satellitedevice continues the issuance of source strobes on the source strobeline at a beginning of a new source strobe event.
 25. A receivingcircuit for detecting and receiving a source strobe event from a sourcestrobed bus, said circuit comprising: a first data circuit for inputtinginformation associated with the source strobe event from the bus, saidfirst data circuit having a first output and being clocked by a sourcestrobe signal associated with the bus; a second data circuit connectedto said first output, said second data circuit having a second outputand being clocked by a second clock signal associated with a clock ofsaid receiving circuit, said second data circuit continuously samplingsaid first output and outputting said second output responsive to saidsecond clock signal; and a change detect circuit connected to receivesaid second output, said change detect circuit determining whether saidsecond data circuit is in a known state and processing the source strobeevent if it is determines that said second data circuit is not in theknown state.
 26. The receiving circuit of claim 25, wherein the knownstate is a bus idle state.
 27. The receiving circuit of claim 25,wherein the information associated with the source strobe event is acommand packet transmitted over the bus from a master of the bus. 28.The receiving circuit of claim 25, wherein said change detect circuitignores the information if it is determined that the second circuit isin the known state.
 29. The receiving circuit of claim 25, wherein saidchange detect circuit determines whether said second data circuit is ina known state by determining whether said second output should bepresently checked and comparing information from said second output toinformation indicative of the known state when it determines that saidsecond output should be checked.
 30. The receiving circuit of claim 29,wherein said change detect circuit determines whether said second outputshould be checked by checking a characteristic of a prior source strobeevent and determining from the checked characteristic whether it ispossible for a new source strobe event to occur at present.
 31. Thereceiving circuit of claim 30, wherein the characteristic is a packetcount of the prior source strobe event.
 32. The receiving circuit ofclaim 25, wherein said first data circuit inputs the information bydetecting the source strobe signal and inputting the information from acommand/address/data portion of the source strobed bus.
 33. Thereceiving circuit of claim 32, wherein said first data circuit generatessimulated source strobes based on the detected source strobe and latchesthe input information using the simulated source strobes.
 34. Areceiving circuit for detecting and receiving a source strobe event froma source strobed bus, said circuit comprising: a source strobe macroconnected to the source strobe bus, said source strobe macro receivingsource strobes from the bus, generating a plurality of additionalstrobes based on the received strobes and outputting said additionalstrobes; a plurality of data macros connected to the source strobe busand to the additional strobes, each of said plurality of data macrosinputting information associated with the source strobe event from thebus and in response to said additional strobes, sampling the informationinto a clock domain associated with a core logic clock of said receivingcircuit and outputting clock domain information; and a change detectcircuit connected to receive said clock domain information and a controlsignal, said change detect circuit in response to said control signaldetermines whether the bus is a known state based on said clock domaininformation and processes the source strobe event when the bus is not inthe known state.
 35. The receiving circuit of claim 34, wherein saidcontrol signal is generated by the core logic when a new source strobeevent is expected.
 36. The receiving circuit of claim 34, wherein saidcontrol signal is generated by the core logic when a characteristic of aprior source strobe event indicates that a new source strobe event mayoccur.
 37. The receiving circuit of claim 36, wherein saidcharacteristic is a packet count of the prior source strobe event. 38.The receiving circuit of claim 34, wherein the source strobe event is adata transfer on the source strobe bus.
 39. The receiving circuit ofclaim 34, wherein the known state is a bus idle state.
 40. The receivingcircuit of claim 34, wherein the information associated with the sourcestrobe event is a command packet transmitted over the bus from a masterof the bus.
 41. The receiving circuit of claim 34, wherein the sourcestrobe bus comprises a second source strobe and said receiving circuitfurther comprises a second strobe macro connected to receive the secondsource strobe, and to generate and output a plurality of secondadditional strobes based on the received additional strobe.
 42. Thereceiving circuit of claim 34, wherein each data macro comprises: astrobe toggle circuit connected to input said additional strobes, saidstrobe toggle circuit generating and outputting toggle strobes tosimulate the additional strobes even if said additional strobes are notreceived; a first data circuit for inputting the information associatedwith the source strobe event from the source strobe bus, said first datacircuit having a first output and being clocked by the generated togglestrobes; and a second data circuit connected to said first output, saidsecond data circuit having a second output connected to said changedetect circuit and being clocked by a clock signal associated with thecore logic clock, said second data circuit continuously sampling saidfirst output and outputting said second output responsive to said clocksignal.
 43. The receiving circuit of claim 34, wherein said changedetect circuit comprises: a plurality of latches, each latch receivingand latching a respective portion of said clock domain information inresponse to a clock signal associated with the core logic clock, eachlatches outputting respective latched clock domain information; aplurality of comparison circuits, each comparison circuit inputting arespective portion of said clock domain information and said latchedclock domain information and determining whether the portions match,each comparison circuit outputting a respective comparison output signalwhen the portions match; and an AND gate connected to receive thecomparison output signals and the control signal, said AND gateoutputting a new source strobe event signal if the comparison outputsignals and the control signal indicate that a new source strobe eventhas occurred.
 44. A processor based system comprising: a processor; alink hub coupled to said processor by a processor bus; a satellitedevice coupled to said link hub by a link bus, said link bus being asource strobed bus, at least one of said satellite device and said linkhub including a receiving circuit for detecting and receiving a sourcestrobe event from said link bus, said receiving circuit comprising: afirst data circuit for inputting information associated with the sourcestrobe event from said bus, said first data circuit having a firstoutput and being clocked by a source strobe signal associated with saidbus; a second data circuit connected to said first output, said seconddata circuit having a second output and being clocked by a second clocksignal associated with a clock of said receiving circuit, said seconddata circuit continuously sampling said first output and outputting saidsecond output responsive to said second clock signal; and a changedetect circuit connected to receive said second output, said changedetect circuit determining whether said second data circuit is in aknown state and processing the source strobe event if it is determinesthat said second data circuit is not in the known state.
 45. The systemof claim 44, wherein the known state is a bus idle state.
 46. The systemof claim 44, wherein the information associated with the source strobeevent is a command packet transmitted over the bus from a master of thebus.
 47. The system of claim 44, wherein said change detect circuitignores the information if it is determined that the second circuit isin the known state.
 48. The system of claim 44, wherein said changedetect circuit determines whether said second data circuit is in a knownstate by determining whether said second output should be presentlychecked and comparing information from said second output to informationindicative of the known state when it determines that said second outputshould be checked.
 49. The system of claim 48, wherein said changedetect circuit determines whether said second output should be checkedby checking a characteristic of a prior source strobe event anddetermining from the checked characteristic whether it is possible for anew source strobe event to occur at present.
 50. The system of claim 49,wherein the characteristic is a packet count of the prior source strobeevent.
 51. The system of claim 44, wherein the other one of said linkhub and said satellite device includes a receiving circuit.
 52. Aprocessor based system comprising: a processor; a link hub coupled tosaid processor by a processor bus; a satellite device coupled to saidlink hub by a link bus, said link bus being a source strobed bus, atleast one of said satellite device and said link hub including areceiving circuit for detecting and receiving a source strobe event fromsaid link bus, said receiving circuit comprising: a source strobe macroconnected to said link bus, said source strobe macro receiving sourcestrobes from said bus, generating a plurality of additional strobesbased on the received strobes and outputting said additional strobes; aplurality of data macros connected to said link bus and to theadditional strobes, each of said plurality of data macros inputtinginformation associated with the source strobe event from said bus and inresponse to said additional strobes, sampling the information into aclock domain associated with a core logic clock of said receivingcircuit and outputting clock domain information; and a change detectcircuit connected to receive said clock domain information and a controlsignal, said change detect circuit in response to said control signaldetermines whether said bus is a known state based on said clock domaininformation and processes the source strobe event when said bus is notin the known state.
 53. The system of claim 52, wherein said controlsignal is generated by the core logic when a new source strobe event isexpected.
 54. The system of claim 52, wherein said control signal isgenerated by the core logic when a characteristic of a prior sourcestrobe event indicates that a new source strobe event may occur.
 55. Thesystem of claim 54, wherein said characteristic is a packet count of theprior source strobe event.
 56. The system of claim 52, wherein thesource strobe event is a data transfer on the source strobe bus.
 57. Thesystem of claim 52, wherein the known state is a bus idle state.
 58. Thesystem of claim 52, wherein the information associated with the sourcestrobe event is a command packet transmitted over said bus from a masterof said bus.
 59. The system of claim 52, wherein said link bus comprisesa second source strobe and said receiving circuit further comprises asecond strobe macro connected to receive the second source strobe, andto generate and output a plurality of second additional strobes based onthe received additional strobe.
 60. The system of claim 52, wherein eachdata macro comprises: a strobe toggle circuit connected to input saidadditional strobes, said strobe toggle circuit generating and outputtingtoggle strobes to simulate the additional strobes even if saidadditional strobes are not received; a first data circuit for inputtingthe information associated with the source strobe event from the sourcestrobe bus, said first data circuit having a first output and beingclocked by the generated toggle strobes; and a second data circuitconnected to said first output, said second data circuit having a secondoutput connected to said change detect circuit and being clocked by aclock signal associated with the core logic clock, said second datacircuit continuously sampling said first output and outputting saidsecond output responsive to said clock signal.
 61. The system of claim52, wherein said change detect circuit comprises: a plurality oflatches, each latch receiving and latching a respective portion of saidclock domain information in response to a clock signal associated withthe core logic clock, each latches outputting respective latched clockdomain information; a plurality of comparison circuits, each comparisoncircuit inputting a respective portion of said clock domain informationand said latched clock domain information and determining whether theportions match, each comparison circuit outputting a respectivecomparison output signal when the portions match; and an AND gateconnected to receive the comparison output signals and the controlsignal, said AND gate outputting a new source strobe event signal if thecomparison output signals and the control signal indicate that a newsource strobe event has occurred.
 62. The system of claim 52, whereinthe other one of said link hub and said satellite device includes areceiving circuit.